1. Field of the Invention
The present invention is directed toward software testing, and more particularly to methods and systems for locating the point of failure in a program.
2. Description of the Related Art
Software may be continually revised and updated during development. When a modified version of a software program runs incorrectly, it may be very difficult to locate where something went wrong in the modified version. Such modifications may include: (1) the program is being optimized by a binary level (or post-link) optimization tool; (2) the program is run on a different platform (e.g., a new hardware or operating system); and (3) the program is recompiled by a new compiler or with a different optimization scheme.
The incorrect behavior may appear in a number of ways, such as, for example, aborting at some point in the execution, or producing incorrect results. One current approach for locating runtime defects involves breaking as close to where the failure is and then carefully comb the code for the improper code. This approach is tedious and time consuming. Moreover, if symbolic information is not available, or if the incorrect behavior is the final result, it becomes even more difficult to locate the point of diversion between the two programs.
Another current approach is to use a graphical user interface (GUI) to parallel debug both correct and incorrect programs, wherein a user selects and sets breakpoints at the same symbolic location in both programs and defines the state data. This approach is described in further detail in Abramson et al. in “Parallel Relative Debugging with Dynamic Data Structures,” 16th International Conference on Parallel and Distributed Computing Systems, pp 22-29, Aug. 13-15, 2003 Reno, Nev., USA. However, this approach requires symbolic information and does not work when none is available. In addition, it requires human control to select the breakpoint and the state data.
Another current approach involves creating a text trace of code in the neighborhood of the problem, containing machine state (e.g., register) changes, for both the correct and in correct programs. This approach does not work unless the location of the failure is known, which is not the case when we have incorrect results. It also does not work if the failure (i.e., diversion) starts much earlier before the external termination failure occurs.
Accordingly, there is a need for an automated technique that, given two programs and a given workload, will pinpoint the specific place where the incorrect program starts differing from the correct one (i.e., the program state has diverged from that of the correct program). For practical purposes, the program state may comprise a subset of the machine registers and/or selected program variables.